Method and system for a service process to provide a service to a client

ABSTRACT

Method and system for a service server to provide a service to a client. The client (C) sets up a secure session to an authentication server (CAP) and sends its identifier and a service request stating the required service. The authentication server verifies the client identifier and sends the service request to a service authorization server (DAP). The authorization server checks whether the required service may be provided and sends the authorized service request to the authentication server. The authentication server generates a token, associated with the authorized service request. Via the secure session, the authentication server sends the address of the relevant service server and the token. The client sends the token to the service server, which then sends the token to the authentication server. The authentication server fetches the service request associated with the token and forwards it to the service server, after which the service server gives the client the required service.

BACKGROUND OF THE INVENTION

[0001] The invention pertains to a method, or system, for a serviceprocess to provide a service to a client. The field of the invention isthe delivery of services via computer networks. Authentication andauthorization of clients by servers pose a problem that has in theorybeen “solved”, but in practice it is a persistent problem full ofpitfalls. The practical result is that the secure (i.e. authenticatedand authorized) provision of service occurs hardly at all on theInternet, and that users have little confidence in existing services.

[0002] Numerous causes are identifiable for this situation, including:

[0003] when a service uses the SSL protocol to authenticate the customerand to make the service provisioning secure, SSL must be capable oftransporting (“tunneling”) the service provisioning protocol. This isnot possible with protocols based on UDP. Simple UDP-based protocols areDNS (Domain Name Service), TFTP (Trivial File Transfer Protocol), SNMP(Simple Network Management Protocol), Syslog protocol, etc. More complexexamples include video and audio streaming (such as RealAudio andRealVideo), multi-user gaming protocols and similar.

[0004] when a service uses IPSEC, the following problem arises. IPSECsets up a secure connection (“transport pipe”) between two machines(computers, routers or combinations thereof), one that is separate fromthe services (client/servers) that use it. Several services may use thesame IPSEC pipe. Use of the IPSEC authentication as an authenticationfor the service is similar to a person accepting the authenticity of thesender of a postcard because the postman is able to identify himselfwith means of identification. Apart from this, IPSEC is a far moredifficult protocol than SSL to operate, both technically and from thepoint of view of security;

[0005] when use is made of a combination of IPSEC and SSL for theabove-mentioned purposes, the transmitted data is encrypted twice (onceby IPSEC, once by SSL), which drastically reduces the speed oftransport, and makes it more difficult to put the connection intooperation. This quickly becomes unacceptable, particularly for real-timedata transport (multimedia services);

[0006] to the extent that authentication and authorization do takeplace, they are usually interwoven with an existing service, whichcauses greater problems as the service itself becomes larger and morecomplex.

SUMMARY OF THE INVENTION

[0007] The invention aims to make it possible to:

[0008] 1) modify in a simple way existing services that do little or noauthentication/authorization, in such a way that they then possessrobust authentication/authorization;

[0009] 2) develop new services whereby the authentication/authorizationpart is separated from the actual service provisioning part.

[0010] The invention comprises reusable components for implementingauthentication and authorization. The invention solves theaforementioned problems by separating responsibilities from processes. Aprotocol will be defined that indicates how these parts communicate witheach other in a way such that a service provider can provide his serviceto an authenticated and authorized customer.

[0011] In a preferred embodiment of the invention, four processes aredistinguishable, i.e.:

[0012] a client process, for example a standard browser such asMicrosoft Internet Explorer, hereafter also referred to as “client”.This process is situated in the security domain of the service user;

[0013] an authentication process, situated in the security domain ofeither the service provider or a trusted third party;

[0014] a service authorization process (DAP). This process—the actualauthorization process where it is determined whether a certain servicecan or cannot be provided to a certain client—is situated in thesecurity domain of the service provider;

[0015] a service process (DP), situated in the security domain of theservice provider. According to the invention, a subset (at least one) ofthe processes may also be used. The method according to the inventionconsists of at least one of the following steps:

[0016] a. the client sets up a secure session—an SSL session, forexample—to an authentication process and sends a client identifier—anX.509 public key certificate, for example—and a service requestindicating which service is required;

[0017] b. the authentication process verifies the client identifier andsends to an authorization process the verified client identifier,preferably with a “degree of certainty” indication regarding theauthenticity of the client identifier, and the service request; thisallows the authorization process to know (1) which service is beingrequested, (2) by whom and (3) it has (preferably) a certain degree ofcertainty (indicated, for example, by Class I, II or III certificates)regarding the identity of client;

[0018] c. the authorization process checks whether the service indicatedin the service request can and may be provided to the client, and sendsback to the authentication process the result of the check in the formof an authorized service request, together with a certain period ofvalidity; the authorized service request represents authorization tostart, within the period of validity, providing the service to theclient;

[0019] d. the authentication process generates a token and associates itwith the authorization issued in the previous step (the authorizedservice request);

[0020] e. the authentication process then sends to the client theaddress of the service process concerned and the token, for example bymeans of an HTML page that contains that address and token as ahyperlink, whereby the browser of the client will be redirected to the(hyperlink) address of the service process;

[0021] f. the client contacts the service process (by means of thehyperlink) and sends the token received from the authentication process(the session between the client and the verification process can beterminated);

[0022] g. the service process sends the token received from the clientto the authentication process;

[0023] h. the authentication process fetches the authorized servicerequest (“authorization”) associated with the token, checks whether theperiod of validity is good and then sends the authorized service requestto the service process. Note that this situation is exactly the same asif no authentication and authorization had taken place and the clientprocess had sent the service request directly to the service process.This is because the client process started the session between theclient and the service process, and the protocol used is the sameprotocol that the service process would have used in other cases forthis purpose;

[0024] i. the service process then provides the service required by theclient.

[0025] The system according to the invention comprises the means forexecuting the above-mentioned steps in the method. The describedinvention has the following advantages:

[0026] 1) the invention uses standard protocols;

[0027] 2) the invention needs to be implemented only on the server side(i.e. where the authentication process, authorization process andservice process have been activated). Popular browsers (such asMicrosoft Internet Explorer, Netscape Navigator and similar) are usablewithout any modifications on the client side;

[0028] 3) no extra support (such as a helpdesk) is needed for end-users;

[0029] 4) with minimal modifications, any electronic service that doesnot (yet) carry out authentication/authorization can use the invention,regardless of the protocol that the service uses;

[0030] 5) the invention does not use sessions set up by a server and, byconsequence, (a) requires no special modifications to firewalls, and (b)is also usable if the client is situated in a network connected to theInternet via Network Address Translation (NAT);

[0031] 6) the invention allows simple separation of business processesand operational processes, while the interfaces between the differentprocesses are also very simple. This makes it easy to avoid a situationwhere a service is created as an inflexible monolithic entity.

REFERENCES

[0032] SSL(ftp://ds.internic.net/internet-drafts/draft-freier-ssl-version3-02.txt).This is an Internet draft dated 18 Nov. 1996. The SSLv3 protocol has notbeen formally standardized but is the de facto standard. The protocoloffers privacy and reliability between two communicating applications(processes). It allows client/server applications to communicate in amanner designed to prevent third parties being able to eavesdrop oncommunication, alter messages or add messages. In the protocol stack,SSL expects a reliable transport protocol (like TCP, but not UDP, forexample) below it.

[0033] IPSEC (http://www.ieff.org/rfc/rfc2401.txt). The purpose of IPSECis to offer various security services for traffic on the IP layer, bothin IPv4 and IPv6 environments. Although IPSEC can form part of servicesecurity, it is unable to make an entire service secure, because IPSECoperates at IP level, and it must be possible to guarantee the securityof services also at higher levels;

[0034] closed systems also exist for authentication/authorization. See,for example, RABO Bank for electronic banking, the EasyPay system ofShell, Digital Postal Stamps of PTT Post and similar. Systems of thiskind have the disadvantage that the customer needs additional hardwarebefore being able to use the services.

IMPLEMENTATION

[0035]FIG. 1 shows an implementation of the invention, representing asystem with four processes, i.e. four hardware/software modules(computers, servers, terminals, etc) on which those processes run andcan contact each other via a network (such as the Internet).

[0036]FIG. 1 shows a client process (C), implemented by means of a webbrowser like Microsoft Internet Explorer on a user's PC, a ClientAuthentication Process (CAP), implemented by means of procedures fromstandard libraries, a Service Authorization Process (DAP) and a ServiceProcess (DP) that can provide a service requested by the user by meansof his/her client (C). Each process falls within one security domain,i.e. one person or authority manages the process and bears theconsequences of what the process does or does not do. Process C, forexample, falls under the security domain of the user, while CAP fallsunder the security domain of the service provider (SP) concerned or atrusted third party, while the DAP and DP fall under the security domainof the service provider.

[0037] In this context, a “protocol” is understood to be a method forallowing two (computer) processes to communicate with each other. Thesemay be Internet protocols, for example, but also procedure calls (if theprocesses run on the same machine), or other protocols. The shownimplementation of the invention uses the following communicationprotocols:

[0038] SSL (Secure Sockets Layer Protocol) or TLS (Transport LayerSecurity protocol). These are well-known and well-documented protocols(see references);

[0039] DSP (Domain Secure Protocol). This is not an existing protocol,but a “place holder” name for any protocol that either (1) providescommunication between two processes within one and the same securitydomain, and (2) has been designated by the administrator of thatsecurity domain as “safe” for use within that security domain, or (1)provides communication between a process in the security domain of a TTPand a process in the security domain of the service provider concerned,and (2) has been designated by the administrators of these securitydomains as “safe” for use within those security domains;

[0040] DSP1, a DSP protocol used between the CAP and DAP processes;

[0041] DSP2, a DPS protocol used between the CAP and DP processes.

[0042] AP (Application Protocol). This is not an existing protocol, buta “place holder” name for the protocol between the client process (C)and the service process (DP). This protocol must satisfy the securityrequirements (and other requirements) laid down by the service providerfor the protocol.

[0043] The procedure is as follows:

[0044] a connection is set up between process C and CAP. This connectionuses the SSL or TLS protocol. The protocol is set in such a way thatduring the set-up of this connection:

[0045] (a) C authenticates the CAP based on a server certificate to besent by the CAP that has been issued by a party known to C (“TrustedThird Party”);

[0046] (b) CAP sends to C a list of client certificate issuers acceptedby CAP. For each certificate type and issuer, the CAP further has thedegree of certainty applied by the service provider for authenticationof certificates of that type and issuer.

[0047] CAP initiates a connection between CAP and DAP, using the DSP 1protocol (see above).

[0048] C initiates a connection between C and DP, using the AP protocol(see above).

[0049] a connection is set up between service process DP and the CAP.This process uses the, DSP2 protocol (see above). DP or CAP can set upthis connection. The invention assumes the existence of an (electronic)“contract” between users and service providers, specifying whichservices the DP may provide to the user and on what conditions. Theseconditions may possibly impose requirements regarding the type ofcertificate a client may submit for authentication, parameters that caninfluence the service, the charge the service provider requires from Cfor providing the required service, etc. The aforementioned servicerequests consist of a set of service parameters and take the form of aparameter list that may be added to a URL. Where reference is made to“authorization”, this term comprises (1) the identity of the user (viathe client C) for whom the authorization is intended, (2) a servicerequest for which the authorization was issued, (3) a validity interval(i.e. a time interval within which the authorization is valid), and (4)an IP address from where the authorization was requested. The servicerequest takes the form of a parameter list added to a URL. Theauthorization further possesses the characteristic that the serviceprovider (SP) has a sufficient degree of certainty that a client forwhom the authorization was created is capable of obtaining access to theservice within the validity interval.

[0050] The “token” referred to above consists of a row of bits that theCAP creates based on an authorization, in such a way that the tokenpossesses the following characteristics:

[0051] (a) CAP can reproduce the authorization (which resulted in thecreation of the token) on the basis of the token, at least during thetime interval within which the authorization Is valid;

[0052] (b) the token is valid for such time as the authorization isvalid;

[0053] (c) the risk of a third party being able to guess a valid tokenis so small as to be negligible (for example, less than 2-50)

[0054] (d) two or more different (valid) authorizations are notsimultaneously associated with one and the same token. As CAP createsand also interprets the token, CAP is able to decide the data includedin the token. The token size is limited (not in theory, but probably inpractice) by:

[0055] the size of the URL of the DP;

[0056] the character set (ASCII) permissible for the token, and

[0057] the maximum length of the URL permitted by the client browser.

[0058] The secure hash (or part thereof) of an authorization convertedto ASCII could be a good token. The diagram in FIG. 2 illustrates howthe presented system works:

[0059] [1] the user surfs to the required service by entering theaddress (URL) (for example, www.service.com) in the browser (client),which causes browser C to set up an SSL connection to the CAP serverconcerned, whereby the client C and the CAP server authenticate eachother (see above under “setting up an SSLITLS connection”). As a resultof this action, CAP has at its disposal the identity of the user C (ID),the public key certificate of C against which the ID was checked, AlvI(being a parameter indicating to what extent service provider truststhis check), and the IP address (IP) from where C set up the connection.

[0060] [2] C sends a service request sreq to CAP (via the SSL connectionjust set up).

[0061] [3] CAP sends the sreq, ID, Alvl and IP to the DAP process (usingthe DSP1 protocol).

[0062] [4] if DAP determines that the user C is not entitled to theservice required by C (for example, because the required serviceprovisioning is not defined by a contract), the protocol will end. IfDAP determines that there is an entitlement to the service, DAP will setan alternative service request that (a) is covered by a contract and (b)resembles sreq as closely as possible. DAP further determines a timeinterval TI (validity interval) within which service provisioning muststart.

[0063] DAP sends authorization (comprising sreq′, TI, ID and IP) to CAP(using the DSP1 protocol).

[0064] [5] DAP sends authorization A (consisting of sreq′, TI, Id andIP) to CAP (using the DSP1 protocol);

[0065] [6] CAP creates a token based on the authorization (A) providedby DAP, with all the properties of a token (see above).

[0066] [7] CAP sends (in the already established SSL session) an HTMLpage to the client, containing a hyperlink to the server DP, suchhyperlink including the token as a parameter, with everything occurringin a way such that the browser switches to this hyperink after a waitingtime of zero seconds. This action terminates the SSL session between Cand CAP (the invented protocol does not yet terminate).

[0067] [8] by interpreting this HTML page, the client browser sets up asession to the server DP according to the CAP protocol specified in thehyperlink. Also, the token is sent to DP by means of this protocol.

[0068] [9] DP sends the token to CAP, as well as the IP address (IP) ofthe client that started the session (using the DSP 2 protocol).

[0069] [10] CAP checks whether a valid authorization accompanies thetoken. If that is not the case, the protocol will terminate. Also, CAPwill find out whether:

[0070] IP is the same as the IP address (IP) stated in theauthorization;

[0071] the current time falls within time interval TI stated in theauthorization. If either of these items is incorrect, the protocolterminates.

[0072] [11] CAP sends to DP the service request (sreq) stated in theauthorization (using the DSP2 protocol).

[0073] [12] DP now starts providing service to C in accordance with theservice request, using the AP protocol, and simultaneously the inventedprotocol ends.

[0074] The following comments need to be made:

[0075] 1. if a process is situated in the security domain of a legalperson, it means that the legal person is responsible for the securityaspects of the process (i.e. he manages the security of this process andbears the consequences of what the process does or does notdo—unintentionally or otherwise—with regard to security).

[0076] 2. the “degree of certainty” Alvi indicates how much trust thebusiness has in the statement that “the customer is called ID”. Afterall, this trust may depend on the degree to which the certificate issuerchecked the identity, and this circumstance is different in the case of,for example, Class I, II and III certificates.

[0077] 3. although the standard refers to certificate issuers, thesituation in practice is that one certificate issuer may issue severaltypes of certificates (for example, Class I, II and III certificates),whereby the conditions on which a certificate type is issued differ fromthose attached to a diferent type of certificate. Consequently, thetrust that a service provider has in different certificate types maydiffer, and every certificate type should have a “degree of certainty”Alvl. However, the “distinguished name” of the issuer as it occurs inthe certificate is also used to indicate these certificate types.Therefore, it is possible to suffice in this instance with sending alist of certificate issuers.

1. Method for a service process to provide a service to a client,characterized by the following steps: a. the client sets up a securesession to an authentication process and sends a client identifier and aservice request indicating which service is required; b. theauthentication process verifies the client identifier and sends to anauthorization process the verified client identifier and the servicerequest; c. the authorization process checks whether the serviceindicated in the service request can and may be provided to the client,and sends the result of the check to the authentication process in theform of an authorized service request that includes a validity period;d. the authentication process generates a token that is associated withthe authorized service request; e. via the secure session, theauthentication process sends to the client the address of the serviceprocess concerned and the token; f. the client contacts the serviceprocess and sends the service process the token received from theauthentication process; g. the service process sends the authenticationprocess the token received from the client; h. the authenticationprocess fetches the authorized service request associated with thetoken, checks whether the validity period is good, and then sends theauthorized service request to the service process; i. the serviceprocess then provides the service required by the client.
 2. Methodaccording to claim 1, with the characteristic that the authenticationprocess in the step described above at b. sends to the authorizationprocess, in addition to the verified client identifier, a “degree ofcertainty” indication concerning the authenticity of the clientidentifier.
 3. System for a service server to provide a service to aclient, with the characteristic that: a. the client includes means forsetting up a secure session to an authentication server and for sendingto that authentication server a client identifier and a service requeststating which service is required; b. the authentication server includesmeans for verifying the client identifier received from the client andfor sending the verified client identifier and the service request to anauthorization server; c. the authorization server includes means forchecking whether the service stated in the service request can and maybe provided to the client, and means for sending back to theauthentication server the result of the check in the form of anauthorized service request, provided with a validity period determinedby the authorization server; d. the authentication server includes meansfor generating a token, associated with the authorized service request;e. the authentication server includes means for sending the client, viathe secure session, the address of the relevant service server and thetoken; f. the client includes means for sending the received token tothe service server; g. the service server includes means for sending tothe authentication server the token received from the client; h. theauthentication server includes means for fetching the authorized servicerequest associated with the token, checking whether the validity periodis good, and then sending the authorized service request to the serviceserver; i. the service server includes means for subsequently providingthe required service to the client.
 4. System according to claim 3, withthe characteristic that the authentication server, in addition toincluding the means mentioned above at b. for verifying the clientidentifier received from the client and sending the verified clientidentifier and the service request to an authorization server, furtherincludes means for calculating a “degree of certainty” indicationregarding the authenticity of the client identifier and for sending thatindication to the authorization server.